… close tenant-enumeration leak (#214)

Same class as the seven prior secure-404 fixes (#174 / #188 /
#192 / #196 / #200 / #204 / #210), applied to the two-level
cascade-scoped PurchaseOrderLine entity:

  polpoh → PurchaseOrderHeader.pohPovId → PurchaseOrderVendor.povCompId

Collapse 403 "exists but not yours" into 404 "Not found." so
scoped callers can't enumerate `polId` populations across the
whole tenant table by status code.

Pinned in `tests/api/purchaseorderline.test.js` with three
controller-level unit tests using stubbed `PurchaseOrderLine.findByPk`
+ spied `auth.isMaster` / `auth.getCompanyId` /
`auth.getCompanyIdByPohId` (the helper that internally walks the
header → vendor → company chain).

Co-authored-by: Aaron K. Clark <akclark@thenetwerk.net>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…e tenant-enumeration leak (#218)

Same class as the eight prior secure-404 fixes (#174 / #188 / #192
/ #196 / #200 / #204 / #210 / #214), applied to the job-cascade-
scoped ProductEntry:

  pentJobId → Job.jobCustId → Customer.custCompId

Collapse 403 "exists but not yours" into 404 "Not found." so
scoped callers can't enumerate `pentId` populations across the
whole tenant table by status code.

Pinned in `tests/api/productentry.test.js` with three controller-
level unit tests, spying on `auth.getCompanyIdByJobId` (which
internally walks the job → customer → company chain).

Co-authored-by: Aaron K. Clark <akclark@thenetwerk.net>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…enant-enumeration leak (#238)

Same class as the 13 prior secure-404 fixes, applied to TimeEntry's
getById / update / remove handlers. TimeEntry is direct-company-
scoped via `teCompId`.

Collapse 403 "exists but not yours" into 404 "Not found." so
scoped callers can't enumerate `teId` populations across the
whole tenant table by status code.

Pinned in `tests/api/timeentry.test.js` with three controller-level
unit tests spying on `auth.isMaster` / `auth.getCompanyId`.

This completes the secure-404 series for the 14 single-resource
domain entities (#174 / #188 / #192 / #196 / #200 / #204 / #210 /
#214 / #218 / #222 / #226 / #230 / #234). Two domain controllers
remain outside the series: VersionInfo (master-gated; different
auth shape) and Customer (large refactor; the `findAndRespond`
helper short-circuits to 200+null on a non-existent id which is
a separate bug worth its own PR).

Co-authored-by: Aaron K. Clark <akclark@thenetwerk.net>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The codebase collapses "exists but not yours" into 404 across every
single-row GET / PATCH / DELETE endpoint so a scoped caller can't
enumerate another tenant's ID range by status code. The pattern
landed across 11 entities (#174, #188, #192, #196, #200, #204,
#210, #214, #218, #222, etc.) but the README never mentioned the
behavior — operators reading the doc table would reasonably
expect 403 on a cross-tenant probe and be surprised by 404.

Add a short subsection in the HTTP-conventions block that explains
the choice, links the behavior to the same getCompanyId scope
check used for 403 paths on other surfaces, and notes that master
keys still see all rows.

Co-authored-by: Aaron K. Clark <akclark@thenetwerk.net>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>